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Abstract 

Recently, Nenadic et al. (2004) proposed the RSA-CEGD protocol for 
certified delivery of e-goods. This is a relatively complex scheme based 
on verifiable and recoverable encrypted signatures (VRES) to guarantee 
properties such as strong fairness and non-repudiation, among others. In 
this paper, we demonstrate how this protocol cannot achieve fairness by 
presenting a severe attack and also pointing out some other weaknesses. 
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1 Introduction 

Interest in protocols for fair exchange of information with non-repudiation stems 
from its importance in many applications where disputes among parties can oc- 
cur. Assurance of these properties enables the deployment of a wide range of 
applications, such as certified e-mail or business transactions through communi- 
cation networks. As a result, fair non-repudiation has experienced an explosion 
of proposals in recent years (see [3] for an excellent survey). 

Nevertheless, fairness and non-repudiation have not been so extensively stud- 
ied as other classic issues, such as confidentiality or authentication. Previous 
experience in these contexts has shown that designing security protocols is an 
error-prone task. Consider, as an illustrative example, a non-repudiation pro- 
tocol proposed in 1996 by Zhou and Gollman [5] that was verified and proved 
correct using three different methods [TJ [9] • Surprisingly, in 2002 Gurgens 
and Rudolph demonstrated the absence of fair non-repudiation in that protocol 
under reasonable assumptions [2]. In this case, possible attacks were detected 
after an analysis performed with a different formalism that considered scenarios 
not checked before. 

The RSA-CEGD protocol [I] was recently proposed for certified delivery of 
e-goods, i.e. commercial products that can be represented in electronic form 
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and transmitted over open networks. The scheme is designed to satisfy six ma- 
jor security requirements: non-repudiation of origin; non-repudiation of receipt; 
strong fairness; e-goods content/quality assurance; e-goods and receipt confi- 
dentiality; and transparency of the STTP. In this paper we demonstrate that 
this protocol suffers from severe security problems, and some of the require- 
ments mentioned above cannot be satisfied. In particular, we present attacks 
that show how the protocol does not assure fairness. 

The rest of this paper is organized as follows. Section [5] introduces the 
notation and briefly reviews the RSA-CEGD protocol. Section [3] discusses the 
vulnerabilities and illustrate them through specific attack scenarios. Finally, 
Section [¥] summarizes the paper by presenting some conclusions. 



2 Overview of the RSA-CEGD protocol 

For readability and completeness, we first provide a brief review of the RSA- 
CEGD protocol. 



2.1 Notation 

Throughout this paper, we will use the same notation introduced by the authors 
in the original paper [4]. The protocol's items and cryptographic symbols are 
described below. 

• P a , Pb, Pt' different protocol parties, where P a is the e-goods provider 
(message sender) and P is the purchaser (message receiver). P t acts as 
a Semi-Trusted Third Party (STTP). 

• D a : e-goods to be purchased. 

• k a - symmetric key used by P a to encrypt D a . 

• r a ■ random prime generated by P a - 

• x a — (r a x k a ) mod n a : encryption of key k a with random number r a 

• CertD a — (desc a , hd a ,h a ,ek a , signcA) '■ certificate for D a issued by a 
CA, where: 

— desc a — description (content summary) of D a 

— hd a = h(Ek a (D a )) : hash value of the encryption of D a with key k a 

— h a — h(D a ) : hash value of D a 

— ek a = E p k a (k a ) : encryption of the key k a with P Q 's public key, pk a 

• E s k a (h a ) : P a 's RSA signature on D a serving as a proof of origin of D a 

• y a = E p k a (r a ) ■ RSA encryption of number r a with key pk a 
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• r;, : random prime generated by p, for the generation of the VRES 
(y b ,x b ,xx b ). 

• rec b — (h a ) db mod n b : P b s receipt for P a 's e-goods D a , i.e. P&'s RSA 
signature on D a 

• {yb,Xb,xxb) ■ A's VRES, where 

— 2/6 = T'fc 66 mod (rib x rifct) : encryption of Tb with P,'s public key. Also 
recoverable by P t 

— Xb = (r b x (h a ) dh ) mod rib — {r b x rec b ) mod rib ■ encryption of recb 
with r b 

— xxb — {rb x E s k bt (h(y b ))) mod n b t : control number that confirms 
the correct use of r b 

• Cbt = {pk b t,w b t, s b t) : P>'s RSA public- key certificate issued by Pt 

• pkbt — (e b t, n b t) : public RSA key related to Cm, with eu = e b 

• sk b t = (d b t,n b t) : private RSA key related to Cbt 

• Wbt = (HsktiPht)^ 1 x d bt ) mod n bt 

• s bt = E skt (h(pk b t,Wbt)) ■ Pt's signature on h(pk bt ,w bt ) 

• s b = E s k b {h(Cbt,y b ,Ua, Pa)) ■ Pb's recovery authorization token. 

2.2 Exchange and recovery sub-protocols 

The RSA-CEGD is an optimistic fair exchange protocol composed of two sub- 
protocols, as shown in Fig. [TJ As usual, the exchange sub-protocol is used to 
carry out the exchange between parties without any TTP's involvement. In case 
the process fails to complete successfully, a recovery protocol can be invoked to 
handle this situation. 

The notion of verifiable and recoverable encrypted signature (VRES) under- 
lies at the core of the RSA-CEGD protocol. A VRES is basically an encrypted 
signature, which acts as a receipt from the receiver's point of view, with two main 
properties. First, it can be verified: the receiver is assured that the VRES con- 
tains the expected signature without obtaining any valuable information about 
the signature itself during the verification process. And second, the receiver is 
assured that the original signature can be recovered with the assistance of a 
designated TTP in case the original sender refuses to do it. 

Due to these two properties, the VRES becomes an interesting cryptographic 
primitive upon which fairness can be provided. The RSA-CEGD protocol relies 
on this element within the general scheme we sketch in what follows: 

1. A ciphers the message with an encryption key and sends it to B. 

2. B generates the VRES of his signature and sends it back to A. 
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Figure 1: The RSA-CEGD protocol. 



3. Upon successful verification of the VRES, A is assured that it is secure 
for her to send the decryption key to B, so he can access the message. 

4. Finally, B sends his original signature to A as a receipt. In case he refuses, 
a TTP can recover the signature from the VRES, thus restoring fairness. 

The RSA-CEGD protocol makes use of a novel VRES method based on the 
RSA system, hence its name. The idea stems from the so-called theory of cross- 
decryption [7], which establishes that an RSA encrypted text can be decrypted 
by using two different keys if both pairs of secret/public keys are appropriately 
chosen. Party B is enforced to use a key of this kind to encrypt the VRES, 
while the TTP retains the other. This way, if subsequently B refuses to provide 
A with his signature, the TTP is able to recover it from the VRES. 

3 Protocol vulnerabilities 

Before stating specific attack scenarios, note that: 

1. The VRES received by party P a in step E2 contains the receipt rec b , 
though it is not directly accessible to her. However, party P a is provided 
with all the information required by the STTP to assist P a in the recovery 
of the receipt, i.e. the authorization token Sb and P b 's certificate C b t- 

2. Items < {xb, xxb, yb), s b , Cbt > do not contain themselves any link to the 
current protocol execution. They only refer to the e-goods D a , the receipt 
recb, an authorization to P a , Pb's certificate, and the random numbers r a 
and rb- 

3. The STTP can restore fairness only upon P a request. Party Pb has no 
means to invoke a recovery sub-protocol. This puts P a in an advantageous 
position with respect to the other party. 
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Figure 2: Scheme of the attack. 

4. The protocol defines a token for non-repudiation of origin which does not 
include information to verify who submitted such a token to Pb- 

Invocation of the recovery sub-protocol by party P a will provide Pb with the 
number r a , thus being able to recover the encryption key and, hence, access 
the e-goods D a . Nevertheless, P a can appeal to the STTP during a different 
protocol execution, since the information required to access the receipt does not 
identify the protocol session. In this scenario, the recovery sub-protocol also 
sends number r a to Pb- However, the protocol specification does not require Pb 
to try the key received on messages of previous exchanges. In other words, is 
not reasonable to assume that Pb stores all proofs he ever received, especially 
those related to previous, unsuccessful exchanges. 

As a result of the scheme outlined above, party P a obtains a valid proof 
(receipt) of Pb having received e-goods D a . Pb, on the other hand, does not 
have access to e-goods D a (or is not aware that he has received the correct 
decryption key). Thus, non-repudiation is not satisfied and the protocol does 
not provide fairness for Pb- This situation is described in detail in the attack 
scenario described in the following section. Furthermore, some other weaknesses 
are pointed out in Section [3T2l 

3.1 A replay attack 

The basic scenario is graphically sketched in Fig. [2l The attack is executed 
through two different protocol runs between the same parties, P a and Pb- This 
is not a strong assumption, since it is reasonable to expect that Pb wishes to 
buy several e-goods from the same seller. 

During the first protocol running, P a carries out step El and then waits for 
the VRES, the authorization token, and P&'s certificate. We assume that P a 



5 



performs the required verifications on these items, so she is assured they are 
valid. At this point, P a aborts the protocol. In fact, there is no abort procedure 
per se, so she only does not continue with step E3. Note as well that P b has no 
means to invoke a recovery sub-protocol in this situation. 
Now P a owns the received items: 

< {x b ,xx b ,y b ),s b ,C bt > 

and also number r a and its signature, y a . From these, P a constructs and stores 
the following message: 

mi =< C bt ,y b ,s b ,y a ,r a > 

Suppose that subsequently P b contacts P a to initiate another exchange aimed 
at buying a different e-good, say D' a . Again, P a follows step El and, after E2, 
she receives: 

< (x' b ,xx' b ,y' b ),s' b ,Cbt > 

from P b . Then, P a aborts the exchange sub-protocol and starts an instance of 
the recovery sub-protocol. According to the protocol semantics, it is expected 
that P a sends the following items to the STTP in step Rl: 

m 2 =< C bt ,y b ,s' b ,y' a ,r' a > 

However, P a chooses mi as the message to send. As this is a valid proof, 
the STTP will recover numbers r b and r a , which will be sent to P a and P b , 
respectively. The key point is that both numbers are not related to the current 
protocol execution, but with the previous one. This way, P a can use r b to obtain 
the receipt rec b contained in mi. Even though P b also receives r a , this number 
is useless for him to recover the key required to access D' a . In fact, this r a might 
provide P b with access to the former e-goods he tried to buy. However, in all 
likelihood he is not aware of this. 

As a result, P a has a valid receipt of P b having received e-goods D a , though 
P b does not actually own it. Therefore, the protocol does not provide fairness 
for P b . 

3.2 Indistinguishability of evidences of origin 

The protocol establishes the item E s k a (h a ) as proof of non-repudiation of origin. 
However, parties' identities are not included in such a token, nor any other 
information related to the current protocol execution. Even using authenticated 
channels, evidences obtained do not link together the sender, the originator, the 
receiver, the current protocol execution, etc. This fact yields to a weakness 
related to the indistinguishability of evidences exchanged during the protocol, 
in particular, evidence of origin (EOO). 

Suppose P a and P b perform a protocol execution, so finally P b obtains D a 
and an EOO = E s k a (h a ), where h a = h(D a ). This evidence does not assure 
itself that P b is the intended receiver. In other words, if the exchange would 
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have been carried out between parties P a and P c , then the EOO received by P c 
would have been identical (assuming that the same symmetric key, k a is used). 
This way, once Pb owns D a and EOO, he might provide another party, P c , with 
both items by using a traditional channel. As a result, P c possesses the e-goods 
coupled with a valid EOO for her. Party P a , on the other hand, does not own 
a receipt issued by P c . Consequently, the protocol neither provides fairness for 

Pa- 
S.3 On the security of a modified RSA-CEGD 

In [5], Nenadic et al. presented a different version of the RSA-CEGD protocol 
with slight modifications. The structure of this new proposal remains unaltered 
with respect to the original version. In particular, items sent by Pf, during step 
E2 are the same that appears in the protocol here studied, i.e. the VRES, the 
authorization token, and P^s certificate. Clearly, the attacks described above 
are still applicable for this version. 

4 Conclusions 

In this paper, we have demonstrated how the RSA-CEGD protocol suffers from 
severe vulnerabilities. Our attacks show up that this scheme can lead to an 
unfair situation for any of the two parties involved in the exchange. To the best 
of our knowledge, the aforementioned weaknesses have not been pointed out 
before. 
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